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Human  Factors  Implications  of  Unmanned  Aircraft  Accidents: 

Flight-Control  Problems 


INTRODUCTION 

Unmanned  aircraft  (UA)  have  suffered  a  dispropor¬ 
tionately  large  number  of  mishaps  relative  to  manned 
aircraft  (Williams,  2004).  In  1996,  the  Air  Force  Scientific 
Advisory  Board  (AFSAB)  identified  the  human/system 
interface  as  the  greatest  deficiency  in  current  UA  designs 
(Worch  et  al. ,  1 996) .  A  recent  review  of  accident  statistics 
for  military  UA  lends  support  to  this  statement.  However, 
the  particular  interface  deficiencies  responsible  for  most 
accidents  differed  across  the  various  systems  (Williams, 
2004). 

In  reviewing  accident  data  for  UA,  two  approaches 
can  be  used.  The  first  is  to  focus  on  a  particular  aircraft 
system,  noting  the  deficiencies  in  the  interface  design 
for  that  system  that  led  to  individual  accidents.  The 
second  is  to  look  at  accidents  across  systems,  focusing 
on  categories  of  mishaps  that  occur  across  a  variety  of 
systems.  The  first  approach  can  result  in  specific  design 
changes  for  a  particular  system.  The  second  can  reveal 
basic  human  factors  issues  that  apply  across  a  variety  of 
systems.  In  this  chapter,  we  will  use  the  second  approach 
and  look  at  UA  accidents  across  a  variety  of  systems  and 
focus  on  categories  of  accidents  involving  flight  control. 
The  success  or  failure  of  UA  will  at  least  in  part  be  deter¬ 
mined  by  how  easily  they  can  be  flown.  Once  the  pilot 
has  been  separated  from  the  aircraft,  designers  are  faced 
with  the  basic  problem  of  how  to  control  the  aircraft 
during  the  flight. 

Three  flight-control  categories  have  been  selected  for 
review.  The  first  category  involves  the  use  of  an  external 
pilot  (EP)  to  control  the  flight  of  the  aircraft.  Basically, 


an  EP  is  a  pilot  that  controls  the  aircraft  using  direct 
line-of-sight,  similarly  to  radio-control  aircraft  hobbyists. 
Flight  using  an  EP  represents  the  most  basic  solution 
to  the  problem  of  separating  the  pilot  from  the  aircraft 
while  still  enabling  the  pilot  to  monitor  the  location  and 
attitude  of  the  aircraft.  Pilot  perspective  is  changed  from 
an  egocentric  to  an  exocentric  point  of  view.  The  problems 
that  this  change  creates  will  be  discussed  later. 

The  second  category  concerns  the  transfer  of  control 
during  flight.  While  transfer  of  control  can  occur  within 
a  manned  cockpit,  it  does  not  entail  the  difficulty  or  va¬ 
riety  of  methods  encountered  with  UA  systems.  Transfer 
of  control  can  occur  in  a  number  of  different  ways,  as 
will  be  discussed  below.  In  addition,  the  protocol  for 
transferring  control  from  one  pilot  to  another  can  differ 
radically  from  system  to  system.  Almost  every  current 
system  has  encountered  mishaps  associated  with  transfer 
of  control.  We  will  review  these  problems  and  look  at 
potential  solutions  for  them. 

The  third  flight-control  category  is  the  automation 
of  flight  control.  Perhaps  because  the  pilot  has  been  re¬ 
moved  from  the  aircraft,  there  seems  to  be  an  unspoken 
goal  of  UA  designers  to  remove  the  pilot  altogether  from 
the  system.  This  involves  automating  all  of  the  flight 
control  responsibilities.  One  of  the  latest  military  UA, 
the  Global  Hawk,  is  totally  automated  from  initial  taxi 
and  takeoff  to  landing.  However,  the  implementation  of 
automation  has  not  prevented  the  occurrence  of  mishaps 
attributed  specifically  to  the  automation.  It  will  be  use¬ 
ful  to  review  some  of  these  mishaps  for  ideas  on  how  to 
improve  these  systems. 
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Rather  than  just  a  statistical  summary  of  accident  data 
related  to  UA,  which  can  be  found  elsewhere  (Manning, 
Rash,  LeDuc,  Nobak,  &  McKeon,  2004;  Williams, 
2004),  this  chapter  will  include  reviews  of  a  number  of 
specific  accidents  related  to  the  categories  listed  above. 
The  intent  is  to  suggest  possible  interventions  to  prevent 
such  accidents  from  occurring. 

External  Piloting 

The  most  basic  solution  for  monitoring  the  position 
and  attitude  of  an  UA  is  through  direct  line-of-sight.  A 
pilot  that  maintains  direct  line-of-sight  with  the  aircraft 
is  usually  referred  to  as  the  external  pilot  (EP),  as  op¬ 
posed  to  an  internal  pilot  (IP)  that  obtains  position  and 
attitude  information  electronically.  Maintaining  visual 
contact  with  the  UA,  the  EP  can  control  the  aircraft 
using  a  hand-held  radio-control  box.  Many  of  these  con¬ 
trol  boxes  are  similar  to  those  used  by  radio-controlled 
aircraft  hobbyists  and  provide  direct  control  of  the  flight 
surfaces  of  the  aircraft  through  the  use  of  joysticks  on  the 
box  (see  Figure  1).  Very  little  automation  is  involved  in 
the  use  of  such  boxes,  which  control  the  flight  surfaces 
of  the  aircraft. 


Figure  1:  Radio  flight-control  box. 


For  those  systems  that  require  an  EP,  statistics  show  that 
controlling  the  UA  during  landing  is  a  difficult  problem 
(Gawron,  1998;  Williams,  2004).  For  example,  with  the 
Hunter  system  flown  by  the  U.S.  Army,  47%  of  the  hu- 
man-factors-related  accidents  occurred  while  landing  the 
aircraft.  An  additional  20%  of  the  accidents  involved  an 
error  by  the  EP  during  takeoff  (Williams,  2004) .  Likewise 
the  Pioneer,  which  also  uses  an  EP,  experiences  a  propor¬ 
tionately  large  number  of  accidents  during  landing.  A 
recent  analysis  of  accident  data  for  the  Pioneer  revealed 
that  the  largest  percentage  of  human  factors  accidents 
(68%)  was  associated  with  difficulties  experienced  by  the 
EP  while  landing  the  aircraft  (Williams,  2004). 


Probably  the  main  reason  for  EP  control  difficulties  is 
that  there  is  an  inconsistent  mapping  between  the  move¬ 
ment  of  the  joystick  and  the  response  of  the  aircraft.  The 
failure  of  a  flight  control  to  perform  consistently  (from 
the  perspective  of  the  pilot)  is  a  violation  of  the  human 
factors  principle  of  motion  compatibility  (McCarley 
&  Wickens,  2005;  Wickens  &  Hollands,  2000).  For 
example,  when  the  aircraft  is  approaching  the  EP,  the 
control  inputs  to  maneuver  the  aircraft  left  and  right  are 
opposite  what  they  would  be  when  the  aircraft  is  moving 
away  from  the  EP.  This  inconsistent  mapping  problem  is 
present  for  any  UA  operated  using  a  traditional  control 
box  via  visual  contact. 

Many  current  systems  have  eliminated  the  need  for  an 
external  pilot  either  by  automating  the  takeoff  and  land¬ 
ing  process  or  by  providing  adequate  visual,  positional, 
and  attitudinal  information  and  control  to  the  internal 
pilot  to  accomplish  these  tasks.  Another  solution  is  to 
make  improvements  to  the  control  interface  for  the 
external  pilot.  Quigley,  Goodrich,  and  Beard  (2004) 
designed  and  tested  a  variety  of  control  interfaces  for 
improving  the  performance  of  the  external  pilot.  These 
interfaces  included  a  direct  manipulation  interface  that 
presents  a  fixed-horizon,  wing-view  representation  from 
the  viewpoint  of  an  observer  behind  the  aircraft,  a  voice- 
controlled  interface,  and  a  physical-icon  interface  that 
is  basically  a  hand-held  model  of  the  aircraft  that,  when 
manipulated,  sends  control  signals  to  the  aircraft  that 
mimic  the  attitude  of  the  model. 

Each  of  the  interfaces  provided  some  benefit  to  the  EP, 
but  each  also  had  drawbacks.  The  physical  icon  interface 
had  the  fastest  response  time  but  did  not  resolve  the  is¬ 
sue  of  inconsistent  mapping.  The  direct  manipulation 
interface  provided  consistent  mapping  of  the  controls 
but  required  frequent  visual  accommodation  adjustments 
between  the  interface  and  the  aircraft.  Finally,  the  voice 
interface  resolved  the  mapping  issue,  as  long  as  the  com¬ 
mands  were  world-centered  (e.g.,  “go  north”),  but  was 
not  as  reliable  or  responsive  as  the  other  interfaces. 

Transfer  of  Control 

One  of  the  activities  unique  to  remotely  piloted  aircraft 
is  the  transfer  of  control  from  one  controlling  system  to 
another.  Transfer  of  control  is  usually  required  in  UA  at 
some  point  during  the  flight  because  of  the  limited  range 
of  the  control  station  and/ or  stationary  pilot.  This  transfer 
can  occur  in  one  of  several  ways.  Gontrol  can  be  trans¬ 
ferred  from  an  external  pilot  to  an  internal  pilot,  from  an 
internal  pilot  in  one  ground  control  station  to  a  pilot  in 
a  second  ground  control  station,  and  from  one  side  of  a 
ground  control  station  to  a  set  of  duplicate  controls  within 
the  same  station.  In  addition,  transfer  of  control  during  a 
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flight  can  occur  from  one  pilot  to  another,  analogous  to 
a  crew  change  in  a  manned  aircraft.  However,  even  this 
control  transfer  is  different  in  a  remotely  piloted  aircraft 
because  the  replacement  crew  does  not  have  to  have  been 
present  in  the  control  area  during  the  flight. 

The  difficulty  in  the  transfer  of  control  is  demonstrated 
by  the  fact  that  problems  with  control  transfer  occur  in 
almost  every  UA  system.  It  will  be  informative  to  review 
various  mishaps  involving  the  transfer  of  control  in  dif¬ 
ferent  systems  to  see  if  there  are  any  constants  across 
these  mishaps. 

Two  mishaps  involving  the  Army’s  Hunter  system 
were  related  to  the  transfer  of  control  of  the  aircraft  (U.S. 
Army,  2004) .  In  the  first  mishap,  a  maintenance  crewman 
turned  off  the  autopilot  capability  of  the  aircraft  during 
routine  maintenance  of  the  aircraft  but  inadvertendy  failed 
to  restore  the  autopilot  functionality  prior  to  returning 
the  aircraft  to  flight  status.  The  aircraft  took  off  under 
the  control  of  the  EP  who  did  not  use  the  autopilot  and 
was  thus  unaware  that  it  was  nonfunctional.  The  mishap 
occurred  after  control  of  the  aircraft  was  handed  off  from 
the  EP  to  the  IP.  The  IP  is  usually  given  control  of  the 
aircraft  with  the  autopilot  functioning  since  the  primary 
means  of  control  by  the  IP  is  through  the  use  of  knobs 
and  dials  for  setting  the  aircraft  heading,  airspeed,  and 
altitude.  Because  the  IP  was  not  expecting  a  nonfunc¬ 
tional  autopilot,  he  failed  to  notice  that  the  aircraft  was 
descending  and  was  unable  to  recover  the  aircraft  before 
it  crashed. 


In  the  second  Hunter  mishap,  control  of  the  aircraft 
was  being  transferred  from  one  EP  to  another  during 
training.  The  EP  receiving  control  neglected  to  complete 
all  control  box  checks  and  failed  to  notice  that  one  of 
the  switches  on  the  box  was  in  the  wrong  position  (Wil¬ 
liams,  2004). 

In  the  case  of  a  U.S.  Army  Shadow  system,  two  air¬ 
craft  were  damaged  during  a  single  mission.  The  first 
was  damaged  due  to  a  failure  of  the  automated  landing 
system.  After  the  accident,  the  ground  control  station 
(GCS)  crew  issued  a  command  to  the  damaged  aircraft 
to  kill  its  engine,  but  because  of  damage  to  the  antenna 
the  command  was  not  received.  That  same  GCS  was  then 
tasked  with  controlling  a  second  Shadow  on  an  approach. 
Unfortunately,  after  taking  control  of  the  second  Shadow, 
the  aircraft  received  the  “engine  kill”  command  that 
was  still  waiting  for  an  acknowledgment  from  the  GCS 
software,  causing  the  second  Shadow  to  also  crash.  This 
accident  was  classified  as  both  a  procedural  error  (because 
the  crew  failed  to  follow  all  checklist  items  prior  to  the 
transfer  of  control  of  the  second  aircraft)  and  a  display 
design  problem  (because  there  was  not  a  clear  indication 
to  the  crew  of  the  status  of  the  “engine  kill”  command 
that  had  been  issued;  Williams,  2004). 

A  more  recent  crash  was  that  of  a  Helios  UA  in  June 
2003.  The  Helios  (Figure  2)  is  intended  to  fly  for  ex¬ 
tended  lengths  of  time  at  very  high  altitudes.  During  a 
flight  test  of  the  Helios  in  June  2003,  the  aircraft  flew 
into  turbulence  that  exceeded  the  maximum  capability  of 


Figure  2:  Helios  UA. 
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the  aircraft,  and  it  broke  apart.  According  to  the  accident 
report,  at  least  one  contributing  factor  to  the  accident 
was  the  high  workload  associated  with  the  control  hand- 
off  procedure.  “Approximately  10  minutes  prior  to  the 
event,  the  pilot  was  progressively  becoming  task-saturated 
with  multiple  demands  on  his  attention.  This  included 
concurrent  concerns  with  the  flight  hand-off  procedure” 
(Noll  et  al.,  2004,  p.  84). 

Yet  another  instance  of  a  problem  with  the  control 
handoff  occurred  during  the  test  of  an  Altair  UA  in 
July  2004.  The  Altair  is  a  derivative  of  the  Predator  B 
unmanned  aircraft.  The  control  station  for  the  Altair 
normally  consists  of  two  pilot  stations  side  by  side,  which 
allows  control  of  the  aircraft  to  be  transferred  from  one 
side  to  the  other  during  flight.  During  a  flight  test,  the 
left  pilot  console  malfunctioned.  The  crew  proceeded 
to  switch  control  to  the  right  seat  pilot  console.  The 
switchover  took  time  to  accomplish  and  during  that 
period  the  aircraft  went  into  its  lost-link  mode.  Uplink 
was  re-established,  but  as  the  right  seat  pilot  console  came 
online,  the  engine  shut  down.  Accounts  of  the  event  from 
observers  suggested  that  the  cause  of  the  shutdown  was 
a  fuel  control  switch  that  was  not  in  the  correct  position 
on  the  right  seat  console.  Fortunately,  the  pilot  used  his 
checklist  to  perform  an  engine  restart  and  managed  to 
successfully  restart  the  engine  and  return  to  the  original 
altitude  (Randy  Sundberg,  personal  communication). 

A  common  theme  across  most  of  these  reported  mishaps 
is  a  lack  of  awareness  of  system  settings  on  the  part  of  the 
receiving  crew.  Sometimes  this  is  because  checklists  are  not 
properly  followed.  Other  times  the  displays  did  not  ad¬ 
equately  present  system  status  information  to  the  pilot. 


Automation 

As  UA  continue  to  proliferate,  the  technology  involved 
with  the  flight-control  system  continues  to  become 
more  and  more  sophisticated.  The  ultimate  solution 
seen  by  many  to  the  problem  of  flight  control  of  UA  is 
to  automate  the  control.  One  reason  for  the  tendency 
to  automate  is  the  difficulties  experienced  by  pilots  in 
controlling  the  aircraft.  External  pilots  have  the  problems 
of  limited  range  and  inconsistent  control  mapping,  as 
was  discussed  earlier.  Internal  pilots  have  the  problems 
of  delayed  control  feedback,  poor  visual  imagery,  a  small 
field  of  view,  and  a  general  lack  of  sensory  cues  (McCar- 
ley  &  Wickens,  2005).  The  degree  of  automation  varies 
a  great  deal  from  system  to  system,  with  some  systems 
having  the  capability  to  be  “hand-flown” (e.g..  Predator) 
while  other  systems  have  flight  control  totally  automated 
from  takeoff  to  landing  (e.g..  Global  Hawk). 

Accidents  involving  flight-control  automation  suggest 
that  it  is  difficult  to  anticipate  all  possible  contingencies 
that  can  occur  during  a  flight  and  that  even  if  the  auto¬ 
mation  functions  as  intended,  unintended  consequences 
can  occur  because  of  events  that  are  not  anticipated.  A 
few  examples  of  unintended  consequences  will  illustrate 
this  point. 

The  first  accident  involves  the  crash  of  a  Navy-owned 
Vertical  Take-off  and  Landing  Tactical  Unmanned  Aerial 
Vehicle  (VTUAV),  called  the  Fire  Scout  (see  Figure  3). 

The  investigation  of  the  accident,  which  occurred  on 
November  4,  2000,  revealed  that  human  error  associ¬ 
ated  with  damage  to  onboard  antennas  during  ground 
handling  led  to  the  accident.  Because  of  the  damage  to 
the  antennas,  an  incorrect  signal  was  emitted,  causing  the 


radar  altimeter  system  to  incorrectly  track  the  altitude. 
The  antennas  gave  a  false  reading  that  indicated  that  the 
Fire  Scout  was  at  an  altitude  of  two  ft  above  the  ground 
when,  in  fact,  it  was  hovering  at  an  altitude  of  500  ft 
(Strikenet,  2001).  After  the  “land”  command  was  given, 
the  aircraft  descended  two  ft  to  498  ft  AGL.  The  guidance 
and  control  system  interpreted  the  incorrect  altitude  signal 
as  an  indication  that  the  Fire  Scout  had  already  landed 
and,  performing  as  designed,  shut  down  the  engine.  The 
aircraft  quickly  lost  altitude  and  crashed. 

A  mishap  of  a  Global  Ffawk  occurred  when  the 
aircraft  suffered  an  inflight  problem  with  temperature 
regulation  of  the  avionics  compartment  and  landed  at 
a  preprogrammed  alternate  airport  for  servicing.  After 
landing,  the  aircraft  was  commanded  to  begin  taxiing. 
Unknown  to  the  crew,  a  taxi  speed  of  155  knots  had 
been  entered  into  the  mission  plan  at  that  particular 
waypoint  by  the  automated  mission  planning  software  in 
use  at  the  time.  The  mission  planning  software  had  been 
programmed  to  set  the  descent  speed  of  the  Global  Ffawk 
to  155  knots.  Any  time  that  two  consecutive  waypoints 
varied  in  altitude  by  more  than  a  specified  amount,  the 
software  set  the  speed  to  be  established  between  those 
waypoints  at  155  knots.  What  was  not  anticipated  by 
the  software  developers  however  was  two  consecutive 
taxi  waypoints  on  the  ground  differing  by  more  than 
the  specified  amount  in  altitude.  The  soitwSiK,  perform¬ 
ing  as  designed,  had  inserted  an  airspeed  of  155  knots 
between  the  waypoints.  The  aircraft  accelerated  to  the 
point  where  it  was  unable  to  negotiate  a  turn  and  ran 
off  of  the  runway,  collapsing  the  nose  gear  and  causing 
extensive  damage  to  the  aircraft. 

The  final  example  is  in  regard  to  the  previously 
mentioned  mishap  involving  the  ffelios  system.  After 
it  entered  turbulent  conditions,  the  Ffelios  pilot  was 
unable  to  provide  adequate  control  inputs  to  avoid  the 
breakup  of  the  aircraft.  According  to  the  mishap  report, 
“The  pilot’s  control  panel  was  designed  to  provide  only 
standard  “autopilot  type”  mode  and  navigation  inputs;  it 
was  not  designed  to  provide  for  direct  pilot-in-the-loop 
control  of  attitude  nor  was  it  designed  to  provide  the  pilot 
[with  the]  capability  to  recognize  an  impending  departure 
from  controlled  flight  or  to  stabilize  the  aircraft”  (Noll 
et  ah,  2004,  p.81). 

In  all  of  these  examples,  we  see  evidence  that  the 
developers  of  the  automation  were  unable  to  predict  all 
possible  contingencies.  This  led  to  situations  in  which 
the  automation  performed  as  designed  but  not  as  an¬ 
ticipated. 


SUMMARY  AND  CONCLUSIONS 

In  this  chapter  we  have  seen  examples  of  three  types 
of  UA  accident  categories.  All  three  categories  focus 
around  a  type  of  control  problem.  External  pilot  control 
problems  are  related  to  the  inconsistent  mapping  of  the 
control  box  to  the  movement  of  the  aircraft.  At  least 
two  solutions  present  themselves.  The  first  solution  is 
to  design  the  control  box  in  such  a  way  as  to  achieve  a 
consistent  mapping.  Quigley  et  al.  (2004)  looked  at  the 
use  of  several  options  for  controlling  the  aircraft,  but  all 
had  drawbacks.  A  second  solution  is  to  eliminate  the 
need  for  an  external  pilot  by  automating  those  portions 
of  flight  that  currently  require  an  external  pilot  or  by 
moving  the  flight  control  to  an  internal  pilot.  Such  a 
solution  has  been  accomplished  with  several  current  UA 
systems.  But  the  use  of  an  internal  pilot  is  affected  by 
factors  such  as  a  limited  fleld-of-  view,  delayed  control 
response  and  feedback,  and  a  lack  of  sensory  cues.  In 
addition,  the  implementation  of  automation  presents  its 
own  problems.  Thus,  it  cannot  be  expected  to  provide 
a  perfect  solution. 

The  problem  of  transfer  of  control  centers  around  the 
fact  that  the  receiver  of  control  is  not  always  fully  aware 
of  the  status  of  the  system.  The  problem  can  be  solved 
by  designing  the  displays  in  such  a  way  that  all  critical 
system  parameters  are  available  to  the  pilot  during  the 
transfer.  Most  research  on  display  design  has  focused  on 
the  task  of  navigation  (e.g.,  Henry,  2001).  Additional 
research  is  needed  to  determine  the  types  of  information 
required  during  the  transfer  of  control  and  useful  ways 
to  depict  that  information. 

Another  method  for  reducing  problems  related  to 
transfer  of  control  is  a  yoked  interface  between  control 
stations  performing  a  han doff  Basically,  the  idea  consists 
of  establishing  a  protocol  between  two  control  stations  (or 
within  stations  if  the  goal  is  to  transfer  control  from  one 
side  to  the  other)  that  ensures  that  all  system  parameters 
of  the  receiving  station  match  those  of  the  sending  sta¬ 
tion.  Transfer  of  the  data  could  be  accomplished  either 
through  the  aircraft  data  link  or  directly  between  the 
stations  as  technology  permitted. 

Automation  problems  occur  because  not  all  circum¬ 
stances  can  be  predicted.  The  inability  to  anticipate  all 
possible  contingencies  leads  to  situations  in  which  the 
system  behaves  as  it  was  designed  but  not  in  a  manner 
that  was  expected.  There  are  at  least  two  solutions  to  this 
problem.  The  first  is  to  design  the  system  in  a  way  that 
keeps  the  pilot  more  aware  of  what  the  aircraft  is  going  to 
do  during  the  flight.  This  requirement,  of  course,  assumes 
that  the  pilot  will  also  have  the  ability  to  intercede  in  the 
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automated  task  that  is  being  performed.  In  implementing 
this  solution,  we  have  to  deal  with  what  is  usually  called 
the  “out-of-the-Ioop”  syndrome  (Endsley  &  Kiris,  1995; 
Moray,  1986;  Wickens  &  Hollands,  2000).  The  out-of- 
the-Ioop  syndrome  refers  to  the  finding  that  humans 
working  with  automation  have  a  diminished  ability  to 
detect  system  errors  and  respond  to  them  by  performing 
the  task  manually. 

The  second  solution  to  the  automation  problem  is  to 
design  the  automation  to  be  more  flexible  so  that,  even 
when  a  particular  contingency  has  not  been  anticipated, 
the  system  is  still  able  to  generate  an  appropriate  response. 
This  is  a  challenge  for  those  developing  “intelligent” 
systems,  and  this  field  is  still  in  its  infancy. 

One  conclusion  that  can  be  derived  from  the  mishaps 
presented  in  this  chapter  is  that  flight  control  of  UA  is 
problematic.  Understanding  the  specific  issues  discussed 
here  should  help  reduce  those  accidents.  However,  as 
the  interfaces  of  these  aircraft  continue  to  evolve,  other 
issues  will  appear.  Much  work  remains  to  improve  the 
user  interface  for  UA.  New  displays,  control-interface 
concepts,  and  improved  automation  systems  remain  to 
be  developed. 
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